home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 1.iso / ARGONET / PD / FILER / DICOTTERY.SPK / !Dicottery / Documents / Timings < prev   
Text File  |  1996-05-10  |  3KB  |  84 lines
  1. Timings for Dicottery v3.04 (Thursday, 9th May 1996)
  2. ----------------------------------------------------
  3.  
  4. Note that though the timings were taken from an old version of Dicottery,
  5. and were taken some time ago, they are still exactly the same, since I
  6. haven't actually changed any compression or decomression code since then.
  7.  
  8. The table of timings below were taken using !Zap as a test application.
  9. Three packages were timed for both compression and decompression, and the
  10. final archive sizes were also recorded.  The packages used were:
  11.  
  12. Dicottery (utility)        v3.04
  13. Dicottery (application)        v3.04
  14. ArcFSr/w            v2.52
  15. SparkFS                v1.27
  16.  
  17. The 'Faster' option was enabled for all of these
  18.  
  19.  
  20.         Compress time    Decompress time        Compressed size
  21.         (mins:secs)    (mins:secs)        (original 1474310)
  22.  
  23. Dicottery    0:25        0:16            820612
  24. !Dicottery    0:35        0:16            820612
  25. ArcFS        2:05        0:40            831477
  26. SparkFS        3:29        0:35            646067
  27.  
  28.  
  29. Dicottery uses LZW compression, which is actually a rather nice method.  It's
  30. very fast and produces quite acceptable results.  However, it's quite
  31. obviously beaten on the results side by SparkFS.  I think SparkFS uses LZH
  32. compression, which by its nature is quite a lot better than LZW, but a LOT
  33. slower too.  This explains the extra time SparkFS takes.  ArcFS, however,
  34. erm.... what's going on here?  It compresses as well as LZW, and takes as
  35. much time as LZH.  Is it using a VERY slow LZW algorithm, or is it using a
  36. poor and very inefficient LZH algorithm?  Either way, it produces worse
  37. results than Dicottery on both time and compression rate.  Strange, but
  38. true.
  39.  
  40. The decompression, however, again shows Dicottery leading the field in terms
  41. of speed.  It's 2.5 times faster than ArcFS and just over 2 times faster
  42. than SparkFS.  *grin*
  43.  
  44.  
  45. So: pros and cons (IMHO)
  46.  
  47. Dicottery:
  48. Pros:    VERY fast
  49.     Good compression
  50.     Self-extracting archives
  51.     Nice user-interface ;-)
  52.     FREEWARE!!!!!!!
  53. Cons:    Not a filing system
  54.     No external decompression as yet (limits archive size)
  55.     Not the best compression ratios
  56.  
  57. SparkFS:
  58. Pros:    VERY good compression ratios
  59.     Archives are multi-platform
  60.     Filing system
  61. Cons:    Very slow
  62.     Commercial - has a price tag
  63.     Archives don't self-extract
  64.  
  65. ArcFS:
  66. Pros:    Filing system
  67.     Archives are multi-platform
  68. Cons:    Very slow
  69.     Commercial
  70.     Archives don't self-extract
  71.     Poor compression for its speed
  72.  
  73.  
  74.  
  75. All timings taken above have been as accurate as I could possibly make them
  76. with the equipment to hand.  This equipment was an analogue wrist-watch and
  77. a RiscPC600.  All speed tests were done on the same computer with the same
  78. applications loaded and in the same screen mode, and all with the 'Faster'
  79. option selected.
  80.  
  81. If you are unhappy about the views expressed in this text file, don't be.
  82. The only actual VIEW that I hold expressed in here is that Dicottery's user
  83. interface looks nice.  Everything else has been written simply from observed
  84. fact and should be taken as such.